M-Bus to LoRaWAN - Secondary Addressing

Integration manual for the ACRIOS Systems converters ACR-CV-101L-M-D and ACR-CV-101L-M-EAC with focus on secondary addressing.

Introduction

This converter is used to retrofit existing meters with M-Bus communication to LoRaWAN communication.

Following link refers to a Lua script used within the documentation, it contains all the mentioned configuration options and functions:

M-Bus to LoRaWAN - Secondary Addressing LUA script

warning

Keep in mind that older M-Bus meters lack secondary addressing because early standards and hardware did not support it. Secondary addressing became widely supported post-2010 as the M-Bus standard evolved and systems scaled in complexity - thus it is safe to assume all models from 2015 and later are compatible. If you encounter issues with older meters, you may need to consider retrofitting or upgrading your network to accommodate modern addressing methods.

Feel free to contact us for possible solutions.

Typical Use-Case

Efficient monitoring and management of heat meters plays a crucial role in optimization of energy consumption and overall operational effectiveness in the realm of district heating stations. The integration of the M-Bus to LoRaWAN converter presents a streamlined solution that allows for quick deployment and seamless connectivity for heat meter data, ensuring real-time insights and efficient control.

Scenario:

Imagine a district heating station serving a residential complex. This facility relies on a network of heat meters installed within individual apartments to monitor the heat consumption accurately. The challenge is to efficiently collect and transmit this consumption data to a central management system for billing, monitoring, and maintenance purposes.

Solution:

To overcome this challenge, the Lua script used in conjunction with ACRIOS Systems's converters incorporates Virtual ID Field Differentiation (VIF DIF) filtering. This addition provides notable benefits, including a significant reduction in transmitted bytes which comes handy given the constraints of LoRaWAN. This is particularly useful since many devices can generate large M-Bus frames.

Benefits:

Time and Cost Savings: The quick installation process eliminates unnecessary configuration and wiring efforts, reducing installation time and associated costs.
Seamless Integration: The plug-and-play nature of the solution simplifies the integration of heat meters into the district heating network, minimizing disruption to residents.
Reliable Communication: The external antenna ensures reliable signal propagation, maintaining consistent communication even in complex architectural environments.
Real-Time Insights: The solution provides real-time heat consumption data, enabling accurate billing and informed decision-making for energy optimization.
Remote Configuration: Both the device configuration and its software can be maintained remotely thanks to the utilization of two-way communication protocol.

What Is M-Bus?

M-Bus (Meter-Bus) is a European standard (EN 13757-2 physical and link layer, EN 13757-3 application layer) for the remote reading of water meter, gas or electricity meters. M-Bus is also usable for other types of consumption meters. The M-Bus interface is made for communication on two wires, which is very cost-efficient. There is also a radio variant of M-Bus (Wireless M-Bus), specified in EN 13757-4.

Data on the M-Bus is transferred in telegrams which consist of one or more frames, there must be no pauses within telegrams, not even after stop bits. M-Bus uses four different telegram formats with the following structures:

Single Character	Short Frame	Control Frame	Long Frame
E5h	Start 10h	Start 68h	Start 68h
	C Field	L Field = 3	L Field
	A Field	L Field = 3	L Field
	Check Sum	Start 68h	Start 68h
	Stop 16h	C Field	C Field
		A Field	A Field
		CI Field	CI Field
		Check Sum	User Data (0-252 Byte)
		Stop 16h	Check Sum
			Stop 16h

❗ When communicating with more meters on the same M-Bus line, it is crucial to provide each slave unit with individual address (A Field). Meter can be addressed by its primary address or by its secondary address.

Primary Addressing:

Address	Function
0	Factory default address.
1-250	Addresses that can be assigned to slaves. (Primary addresses)
251-252	Reserved for future use.
253	Indicates that addressing is performed at the network layer instead. (Secondary addressing procedure)
254	Broadcast, meters reply with their addresses. (Causes collision, test purposes only)
255	Broadcast, meters do not reply.

The secondary address consists of 4 parts:

4 bytes being the device ID (serial #)
2 bytes being the manufacturer’s identifier
1 byte being the device version
1 byte being the device media

The benefit of secondary addressing is that there is no need to reconfigure meter’s primary addresses and the installation can be navigated only by modifying the converters’ addressing mechanism.

Converter Integration

Functions

Adaptable payload fragmentation length
Configurable reading period (default interval: 1 hour)
Configurable initial M-bus delay (default length: 5,000 ms)
Configurable M-Bus parameters
Configurable port
Configurable VIF DIF filtering
Remote configuration using specific commands

Out of the Box Behavior

By default after connecting the meter to the converter and powering up, the device will first scan for any available M-bus devices.

This is how it looks on first onStartup():

Initialization:

[      147][SYS]: console ready
[      150][MEM]: init done, heap 48160 bytes, bss 12472 bytes, stack 4128 bytes
[     2738][SYS]: Reset Reason: BOR reset
[     2742][SYS]: FW version: CV_FW_2.13.7
[     2749][SYS]: Model: ACR_CV_101L_M_D
[     2753][SYS]: SN: 1111
[     2756][SYS]: date / time - 2016/01/01 / 00:00:02
[     2761][SYS]: build date / time - Jan 10 2024 / 22:14:26

Loading the Lua script and starting the onStartup() section:

[     7347][STDOUT]: MBus-LoRaWAN, V2.0
[     7838][STDOUT]: ACR_CV_101L_M_D

M-Bus scan:

[     7910][HWAPI_MBUS]: MBUS FILTER not set!
[    23229][STDOUT]: Params:  1 500 0 1
[    25138][MBUS]: found id = 0x22003287, manid = 0x7704, ver = 0x14, medium = 0x07
[    29287][STDOUT]: Old filter:
[    29330][STDOUT]: 22003287  not in existing, add
[    29394][STDOUT]: New filter:
[    29441][STDOUT]: 1  = 22003287
[    29498][STDOUT]: New VIF DIF filter:
[    29547][STDOUT]: 1  = 00000000

When the scan is finished, the device sends a "Scan done" report. It's distinguished by the third byte F5. More about the command bytes are described in Commands section.

Sending the data to LoRaWAN:

[    29897][STDOUT]: TX:
[    30126][STDOUT]: V =	3605	mV

	00 : 01 01 F5 01 87 32 00 22 77 04 14 07
[    30212][LORA]: Force confirmed message after join!
[    30218][LORA]: Not joined, join and continue.
[    30249][LORAMAC]:  # === MLME-Request == #
[    30254][LORAMAC]: #               MLME_JOIN               #
[    30261][LORAMAC]: # ===== #
[    30265][LORAMAC]: STATUS      : OK
[    30272][LORAMAC]:  # == CTXS STORED == #
[    30277][LORAMAC]: Size        : 1112
[    35514][LORAMAC]:  # === MLME-Confirm == #
[    35519][LORAMAC]: STATUS      : OK
[    35524][LORAMAC]: # ===   JOINED     == #
[    35529][LORAMAC]:  OTAA
[    35532][LORAMAC]: DevAddr     :  0007AAA9
[    35538][LORAMAC]:
[    35540][LORAMAC]: DATA RATE   : DR_4
[    35549][LORAMAC]:  # == CTXS STORED == #
[    35554][LORAMAC]: Size        : 1088
[    35649][LORAMAC]:  # === MCPS-Request == #
[    35655][LORAMAC]: #            MCPS_CONFIRMED             #
[    35662][LORAMAC]: # ===== #
[    35666][LORAMAC]: STATUS      : OK
[    40870][LORAMAC]:  # === MCPS-Confirm == #
[    40876][LORAMAC]: STATUS      : OK
[    40880][LORAMAC]:  # =   UPLINK FRAME        1   = #
[    40887][LORAMAC]:
[    40890][LORAMAC]: CLASS       : A
[    40894][LORAMAC]:
[    40897][LORAMAC]: TX PORT     : 100
[    40901][LORAMAC]: TX DATA     : CONFIRMED - ACK
[    40907][LORAMAC]: 01 01 F5 01 87 32 00 22 77 04 14 07
[    40914][LORAMAC]:
[    40917][LORAMAC]: DATA RATE   : DR_4
[    40922][LORAMAC]: U/L FREQ    : 867300000
[    40927][LORAMAC]: TX POWER    : 0
[    40932][LORAMAC]: CHANNEL MASK: 00FF
[    40937][LORAMAC]:
[    40939][LORAMAC]:  # == MCPS-Indication == #
[    40945][LORAMAC]: STATUS      : OK
[    40949][LORAMAC]:  # =  DOWNLINK FRAME        0  = #
[    40956][LORAMAC]: RX WINDOW   : 1
[    40960][LORAMAC]: RX PORT     : 0
[    40965][LORAMAC]:
[    40967][LORAMAC]: DATA RATE   : DR_4
[    40972][LORAMAC]: RX RSSI     : -87
[    40977][LORAMAC]: RX SNR      : 13
[    40981][LORAMAC]:
[    40987][LORAMAC]:  # == CTXS STORED == #
[    40992][LORAMAC]: Size        : 472
[    41068][LORA]: Continue unconfirmed msg.
[    41103][STDOUT]: RX:

Throughout the sending process, the converter autonomously verifies its connection to the network server. If it detects a lack of connectivity, it automatically initiates a join request. The preceding text illustrates the successful execution of the join procedure.

onWake function:

In this section, the converter sends an M-Bus request to the connected devices and relays the received frame directly to the Network server. When this part is finished, it's followed by a "Gather report" (F4). Finally, the converter transitions into a sleep mode for the designated duration.

[    48246][STDOUT]: TX:
[    48474][STDOUT]: V =	3605	mV
	00 : 01 01 00 68 0F 0F 68 08 00 72 87 32 00 22 77 04
	10 : 14 07 3D 30 00 00 58 16
[    48585][LORAMAC]:  # === MCPS-Request == #
[    48590][LORAMAC]: #            MCPS_CONFIRMED             #
[    48597][LORAMAC]: # ===== #
[    48601][LORAMAC]: STATUS      : OK
...
[    53956][STDOUT]: RX:
[    54039][STDOUT]: TX:
[    54267][STDOUT]: V =	3604	mV
	00 : 01 01 F4 01 01
[    54365][LORAMAC]:  # === MCPS-Request == #
[    54370][LORAMAC]: #            MCPS_CONFIRMED             #
[    54377][LORAMAC]: # ===== #
[    54381][LORAMAC]: STATUS      : OK
...
[    59697][STDOUT]: RX:
[    59705][SYS]: entering sleep mode

For a more comprehensive understanding, please refer to the Commands sections below.

Hardware Used

ACR-CV-101L-M-D - M-Bus to LoRaWAN converter, battery powered
ACR-CV-101L-M-EAC - M-Bus to LoRaWAN converter, externally powered

The converter allows connection to any meter or other device equipped with an M-Bus communication.

Hardware Limitations

The hardware allows connecting up to 5 Unit Loads (UL) to an M-Bus line.
The typical battery lifetime is:

Reading and Sending Interval	Battery Lifetime
15 min	2.7 years
30 min	5.4 years
60 min	10.8 years

This measuring was done with one M-Bus device and VIF DIF filter activated, so the payload fits a single LoRaWAN message.

Calculation was done with a single D-cell battery (19000 mAh).

In case of a longer M-Bus connection (approximately 380 meters between the meter and converter), a termination resistor (5.5 kohm) is required. This applies only for new generation (NG) of M-Bus converter (the device that allows up to 16 UL), low amount of UL and long connection (for example 380m).

Application Limitations

From the nature of LoRaWAN communication it might be needed to adjust the payload size since only up to 51 bytes can be sent with SF12.
- This solution overcomes this limitation by fragmentation of the payload. In addition, VIF DIF filter can be used to reduce the M-Bus frame size and the final payload. It also checks for the current data rate and adjusts the payload size accordingly.
From the nature of LoRaWAN communication it is needed to be cautious when connecting multiple sensors with frequent readings as the communication might be limited by the duty cycle.
- As much as autonomous the communication is, the user still needs to be cautious about the wake-up period and the length of the payload. If the duty cycle exceeds the limit, the device will drop the payload and attempt to send another one next time.

Uplink Commands

F4 - Gather Report Acked
F5 - M-Bus Scan Done
F6 - M-Bus IDs Checksum
FA - Status Report
FE - Configuration Acknowledge

Gather Report (0xF4)

Payload Description

Example	Description	Size	Byte Number
0x01 01	Packet count (1 out of 1)	[2B]	1-2
0xF4	Command byte	[1B]	3
0x02	Relative counter	[1B]	4
0x01	IDs received	[1B]	5

M-Bus Scan Done (0xF5)

Payload Description

Example	Description	Size	Byte Number
0x01 01	Packet count (1 out of 1)	[2B]	1-2
0xF5	Command byte	[1B]	3
0x01	Apply found devices to the filter	[1B]	4
0x60 0x53 0x47 0x01	ID 01475360	[4B]	5-8
0x42 0x04	MAN ID 0442	[2B]	9-10
0x20	Version	[1B]	11
0x02	Medium	[1B]	12
0x31 0x57 0x54 0x01	ID 01545731	[4B]	13-16
0x42 0x04	MAN ID 0442	[2B]	17-18
0x20	Version	[1B]	19
0x02	Medium	[1B]	20
0xXX	N*IDs	[xB]	x

Apply found devices to the filter:

00 - Do not add or apply any IDs.
01 - Add only scanned IDs (if an ID is stored in the memory, but not received during the scan, it is removed).
02 - Add only newly found IDs.

M-Bus IDs Checksum (0xF6)

Payload Description

Example	Description	Size	Byte Number
0x01 01	Packet count (1 out of 1)	[2B]	1-2
0xF6	Command byte	[1B]	3
0x01	Filter length [= N]	[1B]	4
0x87 32 00 23	Checksum	[4B]	5-8

The checksum is calculated with bitwise XOR:

RES1 = 0 ⊕ (ID1) => 0 ⊕ 0x87320020 = 0x87320020
RES2 = (RES1) ⊕ (ID2) => 0x87320020 ⊕ 0x87320021 =  0x01
RES3 = (RES2) ⊕ (ID3) => 0x01 ⊕ 0x87320022 = 0x87320023
…
RESN = (RESN-1) ⊕ (IDN)

The example above shows the checksum for IDs 20003287, 21003287, and 22003287 looks like this: 0x87320023.

Status Report (0xFA)

Payload Description

Example	Description	Size	Byte Number
0x01 01	Packet count (1 out of 1)	[2B]	1-2
0xFA	Command byte	[1B]	3
0x32 2E 30	LUA script ASCII version (2.0)	[3B]	4-6

Configuration Acknowledge (0xFE)

Payload Description

Example	Description	Size	Byte Number
0x01 0x01	Packet count (1 out of 1)	[2B]	1-2
0xFE	Command byte	[1B]	3
0x00	Wake-up period (days)	[1B]	4
0x01	Wake-up period (hours)	[1B]	5
0x00	Wake-up period (minutes)	[1B]	6
0x01	Filter length	[1B]	7
0x01	Configuration version	[1B]	8
0x60 0x09	M-Bus baudrate	[2B]	9-10
0x03	Retry M-Bus reading	[1B]	11
0xB8 0x0B	M-Bus timeout	[2B]	12-13
0x02	OnStartup Scan mode	[1B]	14
0x00	VIF/DIF filter index 1	[1B]	15
0xFF	VIF/DIF filter index 2	[1B]	16
0xFF	VIF/DIF filter index 3	[1B]	17
0xFF	VIF/DIF filter index 4	[1B]	18
0xFF	VIF/DIF filter index 5	[1B]	19
0xFF	VIF/DIF filter index 6	[1B]	20
0xFF	VIF/DIF filter index 7	[1B]	21
0xFF	VIF/DIF filter index 8	[1B]	22
0xFF	VIF/DIF filter index 9	[1B]	23
0xFF	VIF/DIF filter index 10	[1B]	24
0xFF	VIF/DIF filter index 11	[1B]	25
0xFF	VIF/DIF filter index 12	[1B]	26
0xFF	VIF/DIF filter index 13	[1B]	27
0xFF	VIF/DIF filter index 14	[1B]	28
0xFF	VIF/DIF filter index 15	[1B]	29
0xFF	VIF/DIF filter index 16	[1B]	30
0x01	VIF/DIF filter amount	[1B]	31
0x02	VIF/DIF filter bytes	[1B]	32
0x04 0x13	VIF/DIF filter	[2B]	33-34

VIF/DIF filter index X enables/disables a specific VIF/DIF filter for the ID with the given index.

From the example above, the last bytes 01 02 04 13 specify the VIF/DIF filter itself:

01 - is the number of VIF/DIF filters for group 0, which is 1 filter.

02 - is the number of following bytes, which is 2 bytes.

04 13 - is the VIF/DIF filter.

For a more detailed explanation, please see the section Send Configuration (port = 02).

Initial Delay Report (0xF0 0x10)

Payload Description

Example	Description	Size	Byte Number
0x01 01	Packet count (1 out of 1)	[2B]	1-2
0xF0 10	Command byte	[2B]	3-4
0xA0 0F	Initial delay	[2B]	5-6

Downlink Commands

M-Bus filter Configuration (Port = 01)

Payload Description

Clear the Filter

Example 1	Description	Size	Byte Number
0x01	Clear filter command	[1B]	1

Set an M-Bus ID

Example 2	Description	Size	Byte Number
0x87 0x32 0x00 0x22	Set M-Bus ID 22003287	[4B]	1-4

In case of multiple IDs, the downlink payload for IDs 20003287, 21003287, and 22003287 would look like this: 87 32 00 20 87 32 00 21 87 32 00 22

Uplink Response

Command byte F6 which contains XOR checksum of M-Bus IDs

Send a Configuration (Port = 02)

Payload Description

Example	Description	Size	Byte Number
0x00	Wake-up period (days)	[1B]	1
0x00	Wake-up period (hours)	[1B]	2
0x1E	Wake-up period (minutes)	[1B]	3
0x60 0x09	M-Bus baudrate	[2B]	4-5
0x03	Retry M-Bus reading	[1B]	6
0xB8 0x0B	M-Bus timeout	[2B]	7-8
0x02	OnStartup Scan mode	[1B]	9
0x00	VIF/DIF filter index 1	[1B]	10
0xFF	VIF/DIF filter index 2	[1B]	11
0xFF	VIF/DIF filter index 3	[1B]	12
0xFF	VIF/DIF filter index 4	[1B]	13
0xFF	VIF/DIF filter index 5	[1B]	14
0xFF	VIF/DIF filter index 6	[1B]	15
0xFF	VIF/DIF filter index 7	[1B]	16
0xFF	VIF/DIF filter index 8	[1B]	17
0xFF	VIF/DIF filter index 9	[1B]	18
0xFF	VIF/DIF filter index 10	[1B]	19
0xFF	VIF/DIF filter index 11	[1B]	20
0xFF	VIF/DIF filter index 12	[1B]	21
0xFF	VIF/DIF filter index 13	[1B]	22
0xFF	VIF/DIF filter index 14	[1B]	23
0xFF	VIF/DIF filter index 15	[1B]	24
0xFF	VIF/DIF filter index 16	[1B]	25
0x01	VIF/DIF filter amount	[1B]	26
0x02	VIF/DIF filter bytes	[1B]	27
0x04 0x13	VIF/DIF filter	[2B]	28-29

OnStartup Scan mode has 3 options:

00 - disables OnStartup Scan and uses the already stored IDs.
01 - stores only the IDs found during scan and removes all the stored IDs that are not found by the device.
02 - only adds newly found IDs to the list, but keeps the stored ones intact.

VIF/DIF filter index X enables/disables a specific VIF/DIF filter for the ID with the given index.

From the example above, the last bytes 01 02 04 13 specify the VIF/DIF filter itself:

01 - is the number of VIF/DIF filters for group 0, which is 1 filter.

02 - is the number of following bytes, which is 2 bytes.

04 13 - is the VIF/DIF filter.

Let's assume, we need to set-up a VIF/DIF filter for two different devices. We'll need to create a VIF/DIF filter with 2 indexes (index 0 and 1).

The VIF/DIF index specification could look like this:

00 01 FF FF FF FF FF FF FF FF FF FF FF FF FF FF

or this:

01 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF

Depending on which M-Bus ID should use VIF/DIF filter with index 0 or 1 (more below).

An example of VIF/DIF filter specification:

02 03 FD DC FF 03 FD C9 FF 02 03 FD DA FF 03 FD C8 FF

02 - is the number of physical quantities/filters in this first group (index 0)
- 03 - is the number of the following bytes
  - FD DC FF - is the first applied filter in the first group (VIF/DIF - Current)
- 03 - is the number of the following bytes
  - FD C9 FF - is the second applied filter in the first group (VIF/DIF - Voltage)
02 - is the number of physical quantities/filters in this first group (index 1)
- 03 - is the number of the following bytes
  - FD DA FF - is the first applied filter in the second group (VIF/DIF - Current)
- 03 - is the number of the following bytes
  - FD C8 FF - is the second applied filter in the second group (VIF/DIF - Voltage)

Uplink Response

Command byte FE containing a whole configuration (wake-up interval, M-Bus, and VIF/DIF filters)

Request the Configuration (Port = 03)

Example	Description	Size	Byte Number
0x01	Send configuration	[1B]	1

Uplink Response

Command byte FE with configuration

Request an M-Bus Scan (Port = 04)

Payload Description

Example	Description	Size	Byte Number
0x01	Apply newly found devices as new filter	[1B]	1
0xF4 01	M-Bus response timeout (500 ms)	[2B]	2-3
0x00	Filter by string (no option)	[1B]	4

Filter by string can be ID, Manufacturer ID, Version, Medium ...

Uplink Response
A command byte F5 with the following details about found devices:

M-Bus ID
Manufacturer ID
Version
Medium

Request an M-Bus Filter Report (Port = 05)

Example	Description	Size	Byte Number
0x01	Send M-Bus filter report request	[1B]	1

Uplink Response

Command byte F6 with XOR checksum of M-Bus IDs

Request a Status Report (Port = 06)

Example	Description	Size	Byte Number
0x01	Send status report request	[1B]	1

Uplink Response

FA command byte with a Lua script version.

Request a Reset (Port = 07)

Example	Description	Size	Byte Number
0x01	Send reset request	[1B]	1

Executes a device reset. The device starts it with circa three minutes long bootloader sequence and follows with a standard onStartup procedure.

Initial Delay Configuration (Port = 15)

Example	Description	Size	Byte Number
0xA0 0x0F	Set initial delay to 4 000 ms	[2B]	1-2

Uplink Response

Command byte F0 10 with the initial delay value

Request an Initial Delay Report (Port = 16)

Example	Description	Size	Byte Number
0x01	Send initial delay report request	[1B]	1

Uplink Response

Command byte F0 10 with the initial delay value

An Example Application with Itron M-Bus Cyble v2.0

Device used: Itron M-Bus Cyble v2.0

The example below uses the default Lua script. It should demonstrate the plug-and-play solution of the LoRaWAN M-Bus converter in combination with an Itron M-Bus Cyble v2.0. The second part is also an example of configuration through a downlink message.

Initial Setup

As mentioned in the section Out of the Box Behavior, the device initially scans for available M-bus devices. When the scan is finished, the device sends a scan done report.

A scan done report looks in this case like this:

01 01 F5 01 87 32 00 22 77 04 14 07

Then converter sends a standard request to get the M-Bus data:

01 01 00 68 0F 0F 68 08 00 72 87 32 00 22 77 04 14 07 3D 30 00 00 58 16

Detailed payload description:

01 01 - This signifies it is a packet 1 out of 1
00 - This is the M-Bus filter index
68 0F 0F 68 08 00 72 87 32 00 22 77 04 14 07 3D 30 00 00 58 16 - A standard M-Bus frame follows

In this case, the preconfigured VIF/DIF filter is filtering all the data parts from the M-Bus frame, but it will be configured later, so it also sends the Volume parameter.

After that, the device goes to sleep, waking up every hour to send data from the M-Bus device again.

Here is an example of the procedure mentioned above from the perspective of the Network server: Network server log

Remote Configuration

VIF/DIF filter

The full M-Bus frame of the Itron M-Bus Cyble v2.0 looks like this:

56 56 68 08 00 72 87 32 00 22 77 04 14 07 0B
00 00 0C 78 87 32 00 22 0D 7C 08 44 49 20 2E
73 75 63 0A 20 20 20 20 20 20 20 20 20 20 04
6D 1D 14 09 31 02 7C 09 65 6D 69 74 20 2E 74 61
E0 12 04 13 00 00 00 00 04 93 7F 00 00 00 00
13 00 00 00 00 0F 10 00 1F 45 16

If parsed, the payload above would contain these values:

ID: 22003287
MAN:ACW
MED:WATER
GEN:20
ACC:11
STA:48
SIG:0
  DIF:0Ch VIF:78h Data:87320022h - FAB number 22003287
  DIF:0Dh VIF:7Ch Data:20202020202020202020h - DI .tsuc ---
  DIF:04h VIF:6Dh Data:1D140931h -  09.01.2024 20:29
  DIF:02h VIF:7Ch Data:E012h - emit .tab 4832
  DIF:04h VIF:13h Data:00000000h - Volume 0 m³
  DIF:04h VIF:93h VIFE:7Fh Data:00000000h - Volume 0 m³
  DIF:44h VIF:13h Data:00000000h - Volume 0 m³ Storage:1
MDH: 0Fh
MfgData: 10001F

An Example of VIF/DIF Configuration

If we only require the volume in cubic meters, we can configure the VIF/DIF filter to selectively extract the necessary value. Therefore we set the VIF/DIF filter to 04 13.
To do that, we'll use a downlink command with RX port = 2.
The following command also changes the the wake-up period from 1 hour to 30 minutes:

00 00 1E 60 09 03 B8 0B 02 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 01 02 04 13

A Detailed Payload Description:

00 - Wake-up period (days) - 0
00 - Wake-up period (hours) - 0
1E - Wake-up period (minutes) - 30
60 09 - M-Bus baudrate - 2400
03 - Retry M-Bus reading - 3
B8 0B - M-Bus timeout - 3000 ms
02 - onStartup scan mode - 2

info

onStartup scan modes:

0 - No Startup Scan
1 - Add only newly found devices
2 - Add every M-Bus ID found

VIF/DIF configuration section of the payload would be:

00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 01 02 04 13

A Detailed Payload Description:

00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

The example above specifies VIF DIF filter index 0 to M-Bus ID 1

This frame specifies VIF DIF filter index for up to 16 M-Bus IDs

01 - amount of VIF DIF filters for group 0 - 1 filter
02 - amount of following bytes - 2 bytes
04 13 - VIF/DIF filter 1

note

The data received during the LoRaWAN transmission of M-Bus frames are not processed immediately. The commands are executed only during reporting, specifically when the device sends a frame with a command byte (for example F4). Therefore, it is advisable to schedule a downlink when the last M-Bus frame is received.

Here is an example:

Sending The Downlink TTN Downlink

Network Server Log TTN Live Data

As you can see, the network server received confirmation:

01 01 FE 00 00 1E 01 02 60 09 03 B8 0B 02 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 01 02 04 13

The next frame sent by the converter looks like this:

01 01 00 68 15 15 68 08 00 72 87 32 00 22 77 04 14 07 6B 30 00 00 04 13 00 00 00 00 9D 16

Description:

01 01 - packet 1 out of 1
00 - M-Bus ID index 0

The M-Bus Frame:

68 15 15 68 08 00 72 87 32 00 22 77 04 14 07 6B 30 00 00 04 13 00 00 00 00 9D 16

When parsed, the following information is extracted:

HEADER
  ID: 22003287 MAN:ACW MED:WATER GEN:20 ACC:107 STA:48 SIG:0
RECORDS
  DIF:04h (Int32) VIF:13h Data:00000000h Volume 0 m³
MDH: 00h

The outcome of this configuration is a successful application of the VIF/DIF filter and the adjustment of the wake-up period.

M-Bus payload parsing

The payload itself is in a form of typical M-Bus frame, including the header and any M-Bus parser can be used. We recommend using one of the parsers below. Please always check for a possible licensing model.

💡 Alexander Miller M-Bus parser

💡 jMBus parser

💡 libmbus - M-bus Library from Raditex Control

Here is an example using docker to run libmbus service.

💡 ACRIOS Backend

Was anything unclear, missing or hard to understand? Please, contact us at support@acrios.com.

Further information can be found on wiki.acrios.com.

Introduction​

Typical Use-Case​

What Is M-Bus?​

Converter Integration​

Functions​

Out of the Box Behavior​

Hardware Used​

Hardware Limitations​

Application Limitations​

Uplink Commands​

Gather Report (0xF4)​

M-Bus Scan Done (0xF5)​

M-Bus IDs Checksum (0xF6)​

Status Report (0xFA)​

Configuration Acknowledge (0xFE)​

Initial Delay Report (0xF0 0x10)​

Downlink Commands​

M-Bus filter Configuration (Port = 01)​

Clear the Filter​

Set an M-Bus ID​

Send a Configuration (Port = 02)​

Request the Configuration (Port = 03)​

Request an M-Bus Scan (Port = 04)​

Request an M-Bus Filter Report (Port = 05)​

Request a Status Report (Port = 06)​

Request a Reset (Port = 07)​

Initial Delay Configuration (Port = 15)​

Request an Initial Delay Report (Port = 16)​

An Example Application with Itron M-Bus Cyble v2.0​

Initial Setup​

Remote Configuration​

VIF/DIF filter​

M-Bus payload parsing​

Introduction

Typical Use-Case

What Is M-Bus?

Converter Integration

Functions

Out of the Box Behavior

Hardware Used

Hardware Limitations

Application Limitations

Uplink Commands

Gather Report (0xF4)

M-Bus Scan Done (0xF5)

M-Bus IDs Checksum (0xF6)

Status Report (0xFA)

Configuration Acknowledge (0xFE)

Initial Delay Report (0xF0 0x10)

Downlink Commands

M-Bus filter Configuration (Port = 01)

Clear the Filter

Set an M-Bus ID

Send a Configuration (Port = 02)

Request the Configuration (Port = 03)

Request an M-Bus Scan (Port = 04)

Request an M-Bus Filter Report (Port = 05)

Request a Status Report (Port = 06)

Request a Reset (Port = 07)

Initial Delay Configuration (Port = 15)

Request an Initial Delay Report (Port = 16)

An Example Application with Itron M-Bus Cyble v2.0

Initial Setup

Remote Configuration

VIF/DIF filter

M-Bus payload parsing